GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Domain Name System</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Domain Name System</span></h1>

</header>

</div>

<caption style="background:#FFC0FF; font-size:larger;">Domain Name System (DNS)

</caption>

<td><b>Familie:</b>

</td>

<td><a href="Internetprotokollfamilie" title="Internetprotokollfamilie">Internetprotokollfamilie</a>

</td></tr>

<tr>

<td><b>Einsatzgebiet:</b>

</td>

<td><a href="Namensaufl%C3%B6sung" title="Namensauflösung">Namensauflösung</a>

</td></tr>

<tr>

<td><b>Ports:</b></td>

<td>

<p>53/UDP<br> 53/TCP<br> 853/TCP (nur mit TLS, RFC 7858<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>)<br> 853/UDP (nur mit <a href="Datagram_Transport_Layer_Security" title="Datagram Transport Layer Security">DTLS</a>, RFC 8094<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>)

</p>

</td></tr>

<tr>

<caption>DNS im <a href="Internetprotokollfamilie#TCP/IP-Referenzmodell" title="Internetprotokollfamilie">TCP/IP-Protokollstapel</a>:

</caption>

<th class="hintergrundfarbe4">Anwendung

</th>

<th colspan="5" class="notheme hintergrundfarbe6">DNS

</th></tr>

<tr>

<td class="hintergrundfarbe8">Transport

</td>

</td>

</td></tr>

<tr>

<td class="hintergrundfarbe8">Internet

</td>

<td colspan="5" class="notheme" style="background:#EEEEFF; color:#202122;"><a href="Internet_Protocol" title="Internet Protocol">IP</a> (<a href="IPv4" title="IPv4">IPv4</a>, <a href="IPv6" title="IPv6">IPv6</a>)

</td></tr>

<td class="hintergrundfarbe8">Netzzugang

</td>

<td><a href="Ethernet" title="Ethernet">Ethernet</a>

</td>

<td><a href="Token_Bus" title="Token Bus">Token<br>Bus</a>

</td>

<td><a href="Token_Ring" title="Token Ring">Token<br>Ring</a>

</td>

</td>

<td>…

</td></tr></tbody></table>

</td></tr>

<tr>

<td><b>Standards:</b>

</td>

<td>

RFC 1035 (1987)<sup id="cite_ref-RFC1035_4-0" class="reference"><a href="#cite_note-RFC1035-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p>

</td></tr></tbody></table>

<p>Das <b>Domain Name System</b>, deutsch <b>Domain-Namen-System</b>,<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> (<b>DNS</b>) ist ein hierarchisch unterteiltes Bezeichnungssystem in einem meist <a href="Internet_Protocol" title="Internet Protocol">IP</a>-basierten <a href="Rechnernetz" title="Rechnernetz">Netz</a> zur Beantwortung von Anfragen zu Domain-Namen (<a href="Namensaufl%C3%B6sung" title="Namensauflösung">Namensauflösung</a>).

</p><p>Das DNS funktioniert ähnlich wie eine Telefonvermittlung: Der Benutzer kennt die <a href="Domain_(Internet)" title="Domain (Internet)">Domain</a> (den für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel <code>example.org</code>. Diese sendet er als Anfrage in das Internet. Die Domain wird dann dort vom DNS in die zugehörige <a href="IP-Adresse" title="IP-Adresse">IP-Adresse</a> (die „Anschlussnummer“ im Internet) umgewandelt – zum Beispiel eine <a href="IPv4" title="IPv4">IPv4</a>-Adresse der Form <code>192.0.2.42</code> oder eine <a href="IPv6" title="IPv6">IPv6</a>-Adresse wie <code>2001:db8:85a3:8d3:1319:8a2e:370:7347</code> – und führt so zum richtigen Rechner.

</p>

<div class="mw-heading mw-heading2"><h2 id="Überblick"><span id=".C3.9Cberblick"></span>Überblick</h2></div>

<p>Das DNS ist ein weltweit auf Tausenden von <a href="Server" title="Server">Servern</a> verteilter hierarchischer <a href="Verzeichnisdienst" title="Verzeichnisdienst">Verzeichnisdienst</a>, der den <a href="Namensraum" title="Namensraum">Namensraum</a> des Internets verwaltet. Dieser Namensraum ist in sogenannte <a href="Zone_(DNS)" title="Zone (DNS)">Zonen</a> unterteilt, für die jeweils unabhängige Administratoren zuständig sind. Für lokale Anforderungen – etwa innerhalb eines Firmennetzes – ist es auch möglich, ein vom Internet unabhängiges DNS zu betreiben.

</p><p>Hauptsächlich wird das DNS zur Umsetzung von Domainnamen in IP-Adressen (<i><span lang="en">forward lookup</span></i>) benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenketten. So kann man sich einen Domainnamen wie <i>example.org</i> in der Regel leichter merken als die dazugehörende IP-Adresse <code>192.0.32.10</code>. Dieser Punkt gewinnt im Zuge der Einführung von <a href="IPv6" title="IPv6">IPv6</a> noch mehr an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet. So löst sich beispielsweise der Name <i>www.kame.net</i> in die IPv4-Adresse <code>203.178.141.194</code> und die IPv6-Adresse <code>2001:200:dff:fff1:216:3eff:feb1:44d7</code> auf.

</p><p>Ein weiterer Vorteil ist, dass IP-Adressen – etwa von Web-Servern – relativ risikolos geändert werden können. Da Internetteilnehmer nur den (unveränderten) DNS-Namen ansprechen, bleiben ihnen Änderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden können, kann sogar eine einfache <a href="Lastverteilung_per_DNS" title="Lastverteilung per DNS">Lastverteilung per DNS</a> (<i><span lang="en">Load Balancing</span></i>) realisiert werden.

</p><p>Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (<i><a href="Reverse_DNS" class="mw-redirect" title="Reverse DNS"><span lang="en">reverse lookup</span></a></i>) möglich. In Analogie zum Telefonbuch entspricht dies einer Suche nach dem Namen eines Teilnehmers zu einer bekannten Rufnummer, was innerhalb der Telekommunikationsbranche unter dem Namen <a href="Inverssuche" title="Inverssuche">Inverssuche</a> bekannt ist.

</p><p>Das DNS wurde 1983 von <a href="Paul_Mockapetris" title="Paul Mockapetris">Paul Mockapetris</a> entworfen und in RFC 882<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> und RFC 883<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup> beschrieben. Beide wurden inzwischen von RFC 1034<sup id="cite_ref-RFC1034_3-1" class="reference"><a href="#cite_note-RFC1034-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> und RFC 1035<sup id="cite_ref-RFC1035_4-1" class="reference"><a href="#cite_note-RFC1035-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> abgelöst und durch zahlreiche weitere Standards ergänzt. Ursprüngliche Aufgabe war es, die lokalen <i><a href="Hosts" class="mw-redirect" title="Hosts">hosts</a></i>-Dateien abzulösen, die bis dahin für die <a href="Namensaufl%C3%B6sung" title="Namensauflösung">Namensauflösung</a> zuständig waren und der enorm zunehmenden Zahl von Neueinträgen nicht mehr gewachsen waren. Aufgrund der erwiesenermaßen hohen Zuverlässigkeit und Flexibilität wurden nach und nach weitere Datenbestände in das DNS integriert und so den Internetnutzern zur Verfügung gestellt (siehe unten: <a href="#Erweiterungen">Erweiterung des DNS</a>).

</p><p>DNS zeichnet sich aus durch:

</p>

<ul><li>dezentrale Verwaltung,</li>

<li>hierarchische Strukturierung des Namensraums in Baumform,</li>

<li>Eindeutigkeit der Namen,</li>

<li>Erweiterbarkeit.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Domain-Namensraum">Domain-Namensraum</h2></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Domain_(Internet)" title="Domain (Internet)">Domain (Internet)</a></i></div>

<p>Der Domain-Namensraum hat eine <a href="Baum_(Graphentheorie)" title="Baum (Graphentheorie)">baumförmige</a> Struktur. Die <a href="Bl%C3%A4tter_und_innere_Knoten_in_der_Graphentheorie" title="Blätter und innere Knoten in der Graphentheorie">Blätter</a> und <a href="Knoten_(Graphentheorie)" title="Knoten (Graphentheorie)">Knoten</a> des Baumes werden als Labels (<a href="Englische_Sprache" title="Englische Sprache">englisch</a> für Aufschrift) bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels eines Pfades.

</p><p>Labels sind Zeichenketten, die jeweils mindestens ein <a href="Byte" title="Byte">Byte</a> und maximal 63 Bytes lang sind.<sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup> Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird meist weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Somit lautet ein korrekter, vollständiger Domainname (auch <a href="Fully_Qualified_Domain_Name" class="mw-redirect" title="Fully Qualified Domain Name"><span lang="en">Fully Qualified Domain Name</span></a> genannt) zum Beispiel <code>www.example.com.</code> und darf inklusive aller Punkte maximal 255 Bytes lang sein.

</p><p>Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (englisch <i><span lang="en">root</span></i>). Die erste Ebene (beispielsweise <code>com.</code>) wird als <a href="Top-Level-Domain" title="Top-Level-Domain">Top-Level-Domain</a> (TLD) bezeichnet, die zweite (beispielsweise <code>example.com.</code>) als Second-Level-Domains usw.

</p>

<div class="sieheauch" role="navigation" style="font-style:italic;"><span class="sieheauch-text">Siehe auch</span>: <a href="Liste_l%C3%A4nderspezifischer_Top-Level-Domains" title="Liste länderspezifischer Top-Level-Domains">Liste länderspezifischer Top-Level-Domains</a></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Zone_(DNS)" title="Zone (DNS)">Zone (DNS)</a></i></div>

<p>Die Daten des Domain Name Systems sind über eine Vielzahl von Nameservern weltweit verteilt, die durch Verweise untereinander <a href="Lose_Kopplung" title="Lose Kopplung">lose gekoppelt</a> sind. Die Verweise werden <i>Delegierungen</i> (<span style="font-style:normal;font-weight:normal"><a href="Englische_Sprache" title="Englische Sprache">englisch</a></span> <span lang="en-Latn" style="font-style:italic">delegations</span>) genannt und folgen der hierarchischen Struktur des Domain-Baums. Durch die Delegierungen wird der Domain-Namensraum in überschneidungsfreie Bereiche unterteilt, die <a href="Zone_(DNS)" title="Zone (DNS)">Zonen</a> genannt werden. Ein oder mehrere autoritative Nameserver sind für die Auslieferung der Daten einer Zone zuständig. So sind beispielsweise die <a href="Root-Nameserver" title="Root-Nameserver">Root-Nameserver</a> für die Beantwortung von Anfragen an die Wurzel-Zone zuständig und die Nameserver von <a href="Verisign" title="Verisign">Verisign</a> für die Zone der Top-Level-Domain <a href=".com" title=".com">.com</a>.

</p><p>Eine Zone besteht aus einer Liste von <a href="Resource_Record" title="Resource Record">Resource Records</a>. Der <a href="BIND" title="BIND">BIND</a>-Nameserver sowie dazu kompatible Nameserver-Software speichert die Resource Records in einer <a href="Zonendatei" title="Zonendatei">Zonendatei</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Resource_Record">Resource Record</h3></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Resource_Record" title="Resource Record">Resource Record</a></i></div>

<p>Ein Resource Record ist ein <a href="Datensatz" title="Datensatz">Datensatz</a> im Domain Name System. Er besteht aus fünf <a href="Datenfeld" title="Datenfeld">Datenfeldern</a>. Beispiel:

</p>

<pre>www.example.com. 86400 IN A 93.184.216.34

</pre>

<dd>Der Domainname, unter dem der Resource Record abgelegt ist (beispielsweise <code>www.example.com.</code>).</dd>

<dd>Maximale Zeit in Sekunden, für die dieser Record in einem <a href="DNS-Caching" title="DNS-Caching">DNS-Cache</a> zwischengespeichert werden kann (beispielsweise 86400 Sekunden = 1 Tag).</dd>

<dt>Klasse</dt>

<dd>Fast ausschließlich „IN“ für <a href="Internet" title="Internet">Internet</a>.</dd>

<dd>Datentyp der <a href="Nutzdaten" title="Nutzdaten">Nutzdaten</a> (beispielsweise <a href="A_Resource_Record" title="A Resource Record">A Resource Record</a>: eine IPv4-Adresse).</dd>

<dt>Daten</dt>

<dd>Die eigentlichen Nutzdaten (beispielsweise <code>93.184.216.34</code>).</dd></dl>

<p>Der Abruf eines Resource Records erfolgt unter Angabe von Domainname, Klasse und Typ. Da als Klasse nahezu ausschließlich „IN“ verwendet wird, sind in der Praxis lediglich der Domainname und Record-Typ relevant. Es sind mehrere Dutzend Record-Typen spezifiziert, die unterschiedlichen Anwendungszwecken dienen.<sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup> Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Zu den am häufigsten verwendeten gehören die folgenden Record-Typen:

</p>

<caption>Ausgewählte Resource-Record-Typen

</caption>

<th>Typ

</th>

<th>Zweck/Beschreibung

</th>

<th>Typische Verwendung / Beispiel

</th></tr>

<tr>

</td>

<td>Enthält grundlegende Zonenparameter (Primary-Nameserver, verantwortliche Person, Seriennummer, Refresh-/Retry-/Expire-Werte, Minimum-TTL).

</td>

<td>Beginn einer Zonendatei, z. B. für <i>example.com</i>.

</td></tr>

<tr>

</td>

<td>Gibt an, welche Nameserver für eine Zone zuständig sind (Delegierung).

</td>

<td>Delegierung von <i>example.com</i> auf <i>ns1.example.net.</i> und <i>ns2.example.net.</i>

</td></tr>

<tr>

</td>

<td>Weist einem Namen eine IPv4-Adresse zu.

</td>

<td><i>www.example.com</i> → 93.184.216.34

</td></tr>

<tr>

</td>

<td>Weist einem Namen eine IPv6-Adresse zu.

</td>

<td><i>www.example.com</i> → 2001:db8::1234

</td></tr>

<tr>

<td><b>CNAME</b>

</td>

<td>Alias-Eintrag: verweist einen Namen auf einen anderen Namen.

</td>

<td><i>www.example.com</i> → <i>webserver.example.com</i>

</td></tr>

<tr>

</td>

<td>Gibt die für den E-Mail-Empfang zuständigen Mailserver einer Domain an (mit Priorität).

</td>

<td><i>example.com</i> → <i>10 mail.example.com</i>

</td></tr>

<tr>

</td>

<td>Beschreibt den Standort (Host, Port, Priorität, Gewichtung) eines bestimmten Dienstes.

</td>

<td><i>_sip._tcp.example.com</i> → SIP-Server von <i>example.com</i>

</td></tr>

<tr>

</td>

<td>Weist einer IP-Adresse einen Namen zu (Reverse DNS).

</td>

<td><i>34.216.184.93.in-addr.arpa</i> → <i>www.example.com</i>

</td></tr>

<tr>

</td>

<td>Frei definierbarer Text; wird u. a. für Policies, Metadaten und Schlüsselmaterial verwendet.

</td>

<td>SPF-Informationen, DKIM-Schlüssel oder DMARC-Policy für <i>example.com</i>

</td></tr>

<tr>

</td>

<td>Historischer RR-Typ für SPF-Informationen (E-Mail-Sender-Policy); in aktuellen Implementierungen wird SPF üblicherweise ausschließlich über TXT-Records veröffentlicht.

</td>

<td>Vorhandene SPF-Records werden von vielen Systemen ignoriert, stattdessen wird der TXT-Record ausgewertet.

</td></tr>

<tr>

</td>

<td>Legt fest, welche Zertifizierungsstellen (CAs) für eine Domain Zertifikate ausstellen dürfen.

</td>

<td><i>example.com</i> erlaubt nur Zertifikate von <i>letsencrypt.org</i>

</td></tr>

<tr>

</td>

<td>Delegation Signer: stellt in der Elternzone einen kryptographischen Verweis auf den öffentlichen Schlüssel der Kindzone bereit (DNSSEC-Chain-of-Trust).

</td>

<td>DS-Record für <i>example.com</i> in der Zone <i>.com</i>

</td></tr>

<tr>

<td><b>DNSKEY</b>

</td>

<td>Enthält die öffentlichen Schlüssel einer Zone für DNSSEC-Signaturen.

</td>

<td>Validierung signierter Antworten für <i>example.com</i>

</td></tr>

<tr>

</td>

<td>Ermöglichen kryptographisch gesicherte negative Antworten (»Name/Typ existiert nicht«), indem sie zusammenhängende Bereiche vorhandener Namen und Typen angeben.

</td>

<td>Signierte NXDOMAIN- und »no data«-Antworten für <i>example.com</i>

</td></tr>

<tr>

</td>

<td>Hinterlegt Zertifikatsinformationen für DANE (z. B. zur Absicherung von TLS-Verbindungen zusätzlich oder alternativ zu klassischen CAs).

</td>

<td><i>_25._tcp.mail.example.com</i>: DANE-Eintrag für SMTP mit TLS

</td></tr>

<tr>

</td>

<td>Allgemeiner Service-Beschreibungsrecord, mit dem flexible Angaben zu Diensten und Endpunkten gemacht werden können (z. B. alternative Ziele, Protokollparameter).

</td>

<td>Angabe mehrerer Ziele/Endpunkte für einen Dienst unter <i>example.com</i>

</td></tr>

<tr>

<td><b>HTTPS</b>

</td>

<td>Spezialisierter SVCB-Typ für HTTPS-Dienste; ermöglicht z. B. die Beschreibung von HTTPS-Endpunkten, Protokollparametern und Alternativzielen.

</td>

<td><i><a rel="nofollow" class="external free" href="https://example.com">https://example.com</a></i> mit Angabe eines bevorzugten Endpunkts und ALPN-Parametern

</td></tr></tbody></table>

<div class="mw-heading mw-heading2"><h2 id="Komponenten">Komponenten</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Nameserver">Nameserver</h3></div>

<p>Ein <b>Nameserver</b> ist ein <a href="Server_(Software)" title="Server (Software)">Server</a>, der <a href="Namensaufl%C3%B6sung" title="Namensauflösung">Namensauflösung</a> anbietet. Namensauflösung ist das Verfahren, das es ermöglicht, Namen von Rechnern bzw. Diensten in eine vom Computer bearbeitbare Adresse aufzulösen (z. B. <i>www.wikipedia.org</i> in <i>91.198.174.192</i>).

</p><p>Die meisten Nameserver sind Teil des Domain Systems, das auch im <a href="Internet" title="Internet">Internet</a> benutzt wird.

</p><p>Nameserver sind zum einen Programme, die auf Basis einer DNS-<a href="Datenbank" title="Datenbank">Datenbank</a> Anfragen zum Domain-Namensraum beantworten. Im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme zum Einsatz kommen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.

</p><p>Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese Zone werden deshalb als <i>gesichert</i> angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im <a href="SOA_Resource_Record" title="SOA Resource Record">SOA Resource Record</a> einer <a href="Zonendatei" title="Zonendatei">Zonendatei</a> aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als <a href="Server" title="Server">Server</a>-<a href="Rechnerverbund" title="Rechnerverbund">Cluster</a> realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per <a href="Zonentransfer" title="Zonentransfer">Zonentransfer</a>.

</p><p>Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand. Seine Informationen werden als <i>nicht gesichert</i> angesehen. Da sich DNS-Daten normalerweise nur sehr selten ändern, speichern nicht-autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen <a href="Halbleiterspeicher#Wahlfreier_Zugriff" title="Halbleiterspeicher">RAM</a> ab, damit diese bei einer erneuten Anfrage schneller vorliegen. Diese Technik wird als <a href="DNS-Caching" title="DNS-Caching">Caching</a> bezeichnet. Jeder dieser Einträge besitzt ein eigenes Verfallsdatum (<a href="Time_to_Live" title="Time to Live">TTL</a> <i>time to live</i>), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das kann unter Umständen bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefert, wenn sich die Daten zwischenzeitlich geändert haben.

</p><p>Ein Spezialfall ist der Caching-Only-Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich und muss alle eintreffenden Anfragen über weitere Nameserver (Forwarder) auflösen. Dafür stehen verschiedene Strategien zur Verfügung:

</p><p><b>Zusammenarbeit der einzelnen Nameserver</b>

</p><p>Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien:

</p>

<dl><dt>Delegierung</dt>

<dd>Teile des Namensraumes einer Domain werden oft an <a href="Domain_(Internet)#Subdomain" title="Domain (Internet)">Subdomains</a> mit dann eigens zuständigen Nameservern ausgelagert. Ein Nameserver einer Domäne kennt die zuständigen Nameserver für diese Subdomains aus seiner Zonendatei und delegiert Anfragen zu diesem untergeordneten Namensraum an einen dieser Nameserver.</dd>

<dt>Weiterleitung (forwarding)</dt>

<dd>Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.</dd>

<dt>Auflösung über die Root-Nameserver</dt>

<dd>Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die <a href="Root-Nameserver" title="Root-Nameserver">Root-Nameserver</a> befragt. Dazu werden in Form einer statischen Datei die Namen und IP-Adressen der Root-Server hinterlegt. Es gibt 13 Root-Server (Server A bis M). Die Root-Server beantworten ausschließlich <a href="Rekursive_und_iterative_Namensaufl%C3%B6sung" title="Rekursive und iterative Namensauflösung">iterative</a> Anfragen. Sie wären sonst mit der Anzahl der Anfragen schlicht überlastet.</dd></dl>

<p>Anders konzipierte Namensauflösungen durch Server, wie der <a href="NetWare" title="NetWare">NetWare Name Service</a> oder der <a href="Windows_Internet_Naming_Service" title="Windows Internet Naming Service">Windows Internet Naming Service</a>, sind meistens auf <a href="Local_Area_Network" title="Local Area Network">Local Area Networks</a> beschränkt und werden zunehmend von der <a href="Internetprotokollfamilie" title="Internetprotokollfamilie">Internetprotokollfamilie</a> verdrängt.

</p>

<div class="mw-heading mw-heading3"><h3 id="Resolver">Resolver</h3></div>

<p>Ein <b>Resolver</b> ist eine Software-Komponente, die per DNS-Protokoll Informationen von einem Nameserver abruft.<sup id="cite_ref-rfc8499_10-0" class="reference"><a href="#cite_note-rfc8499-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup> Die Anwendung, zum Beispiel ein <a href="Webbrowser" title="Webbrowser">Webbrowser</a>, fordert per <a href="Programmierschnittstelle" title="Programmierschnittstelle">Programmierschnittstelle</a> vom Resolver die Auflösung eines Domainnamens an. Der Resolver führt entweder eine <a href="Rekursive_und_iterative_Namensaufl%C3%B6sung" title="Rekursive und iterative Namensauflösung">rekursive oder iterative Namensauflösung</a> durch und gibt die Antwort an die Anwendung zurück.

</p><p>Im rekursiven Modus schickt der Resolver eine rekursive Anfrage an den ihm zugeordneten Nameserver. Hat dieser die gewünschte Information nicht im eigenen Datenbestand, so kontaktiert der Nameserver weitere Server – und zwar solange, bis er eine positive oder negative Antwort erhält. Der Nameserver, der die rekursive Anfrage bearbeitet, verwendet selbst einen eigenen Resolver zur Abfrage anderer Nameserver. Ein Nameserver, der rekursive Namensauflösung anbietet, wird als rekursiver Nameserver oder teilweise auch als rekursiver Resolver bezeichnet.<sup id="cite_ref-rfc8499_10-1" class="reference"><a href="#cite_note-rfc8499-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>

</p><p>Im iterativen Modus bekommt der Resolver entweder den gewünschten <a href="Resource_Record" title="Resource Record">Resource Record</a> oder einen Verweis auf weitere Nameserver, die er selbst als Nächstes fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver, bis er von dem autoritativen Nameserver eine verbindliche Antwort erhält. Während beim rekursiven Modus dem angefragten Nameserver die vollständige Auflösung überlassen wird, muss beim iterativen Modus der Resolver selbst durch wiederholte (iterative) Anfragen die Auflösung übernehmen.

</p><p>Jedes Betriebssystem mit <a href="TCP/IP" class="mw-redirect" title="TCP/IP">TCP/IP</a>-Netzwerkfunktionalität enthält einen Resolver. Üblicherweise handelt es sich dabei um einen simplen Resolver, der ausschließlich rekursive Anfragen an einen konfigurierbaren Nameserver stellen kann. Ein solcher Resolver wird als <i>Stub-Resolver</i> (von <span style="font-style:normal;font-weight:normal"><a href="Englische_Sprache" title="Englische Sprache">englisch</a></span> <span lang="en-Latn" style="font-style:italic">stub</span>: Stumpf oder Stummel) bezeichnet.<sup id="cite_ref-rfc8499_10-2" class="reference"><a href="#cite_note-rfc8499-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup>

</p><p>Bekannte Kommandozeilen-Programme zur Namensauflösung sind <a href="Nslookup" title="Nslookup">nslookup</a>, host und <a href="Dig_(Software)" title="Dig (Software)">dig</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Protokoll">Protokoll</h3></div>

<p>DNS-Anfragen werden normalerweise per <a href="User_Datagram_Protocol" title="User Datagram Protocol">UDP</a> <a href="Port_(Netzwerkadresse)" title="Port (Netzwerkadresse)">Port</a> 53 zum Namensserver gesendet. Der DNS-Standard fordert aber auch die Unterstützung von <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a> für Fragen, deren Antworten zu groß für UDP-Übertragungen sind.<sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup> Ursprünglich betrug die maximal zulässige Länge einer DNS-Nachricht über UDP 512 <a href="Byte" title="Byte">Bytes</a>.<sup id="cite_ref-12" class="reference"><a href="#cite_note-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup> Mit <a href="Extended_DNS" title="Extended DNS">Extended DNS</a> (EDNS) wurde diese Größenbeschränkung aufgehoben und kann variabel zwischen Client und Server gewählt werden.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup> Beim DNS Flag Day 2020, einer Informationsinitiative von DNS-Software- und DNS-Service-Anbietern, wurde eine standardmäßige Maximallänge von 1232 Bytes empfohlen.<sup id="cite_ref-flagday2020_14-0" class="reference"><a href="#cite_note-flagday2020-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup> Die maximal mögliche Nachrichtenlänge wird durch die <a href="Maximum_Transmission_Unit" title="Maximum Transmission Unit">Maximum Transmission Unit</a> begrenzt. Der Einsatz von <a href="IP-Fragmentierung" title="IP-Fragmentierung">IP-Fragmentierung</a> ist zwar möglich, wird aber nicht empfohlen.<sup id="cite_ref-flagday2020_14-1" class="reference"><a href="#cite_note-flagday2020-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-15" class="reference"><a href="#cite_note-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup>

</p><p>Überlange Antworten werden abgeschnitten übertragen, sodass sie die maximal mögliche Nachrichtenlänge des Antwortenden nicht übersteigen, und mit dem Header-Flag <i>Truncated</i> (TC) als solches markiert. Der Anfragende kann daraufhin die Anfrage über TCP wiederholen.<sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup> Bei TCP beträgt die maximale Nachrichtenlänge 65.535 Bytes.<sup id="cite_ref-rfc5936_17-0" class="reference"><a href="#cite_note-rfc5936-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup> Die Verwendung von <a href="Persistenz_(Informatik)" title="Persistenz (Informatik)">persistenten</a> Verbindungen und <a href="HTTP-Pipelining" title="HTTP-Pipelining">Pipelining</a> ist möglich.<sup id="cite_ref-18" class="reference"><a href="#cite_note-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup> <a href="Zonentransfer" title="Zonentransfer">Zonentransfers</a> werden stets über TCP durchgeführt, wobei die Nachrichtenlängenbeschränkung dafür nicht relevant ist.<sup id="cite_ref-rfc5936_17-1" class="reference"><a href="#cite_note-rfc5936-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="DNS-Namensauflösung"><span id="DNS-Namensaufl.C3.B6sung"></span>DNS-Namensauflösung</h2></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Rekursive_und_iterative_Namensaufl%C3%B6sung" title="Rekursive und iterative Namensauflösung">Rekursive und iterative Namensauflösung</a></i></div>

<p>Angenommen, ein Client will eine Verbindung zu einem Webserver unter dem Domainnamen <code>de.wikipedia.org.</code> aufbauen. Dazu braucht er dessen IP-Adresse. In den folgenden Schritten wird ein exemplarischer Ablauf beschrieben. Bei Verwendung von <a href="IPv4" title="IPv4">IPv4</a> ruft der Client den <a href="A_Resource_Record" title="A Resource Record">A Resource Record</a> und bei <a href="IPv6" title="IPv6">IPv6</a> den <a href="AAAA_Resource_Record" title="AAAA Resource Record">AAAA Resource Record</a> ab. Bei <a href="Dual-Stack" class="mw-redirect" title="Dual-Stack">Dual-Stack</a> fragt der Client beide Adresstypen gleichzeitig ab und wählt die zu verwendende Zieladresse über einen Algorithmus aus, wobei standardmäßig IPv6 bevorzugt wird.<sup id="cite_ref-19" class="reference"><a href="#cite_note-19"><span class="cite-bracket">[</span>19<span class="cite-bracket">]</span></a></sup>

</p>

<ol><li>Das <a href="Betriebssystem" title="Betriebssystem">Betriebssystem</a> des Clients verwendet zunächst lokale Mechanismen zur Namensauflösung, wie beispielsweise eine <a href="Hosts_(Datei)" title="Hosts (Datei)">Hosts-Datei</a>. Diese Mechanismen sind kein Bestandteil des Domain Name Systems und sind hier nur der Vollständigkeit halber erwähnt. Falls sie kein Ergebnis liefern, beginnt die eigentliche DNS-Namensauflösung.</li>

<li>Der (Stub-)Resolver des Betriebssystems fragt den Domainnamen <code>de.wikipedia.org.</code> beim zugeordneten Nameserver ab. Die IP-Adresse des Nameservers wurde entweder manuell eingetragen oder automatisch per <a href="Dynamic_Host_Configuration_Protocol" title="Dynamic Host Configuration Protocol">DHCP</a>, <a href="DHCPv6" class="mw-redirect" title="DHCPv6">DHCPv6</a> oder <a href="Neighbor_Discovery_Protocol" title="Neighbor Discovery Protocol">NDP</a> zugewiesen.</li>

<li>Hat der angefragte Nameserver den Namen im <a href="DNS-Caching" title="DNS-Caching">DNS-Cache</a> zwischengespeichert, antwortet er damit, was die Namensauflösung abschließt (siehe letzter Punkt). Andernfalls erbringt er die Funktionalität eines rekursiven Resolvers.</li>

<li>Der rekursive Resolver fragt einen der 13 <a href="Root-Nameserver" title="Root-Nameserver">Root-Nameserver</a> nach <code>de.wikipedia.org.</code> Der Root-Nameserver antwortet mit einem Verweis auf die Nameserver der <a href="Top-Level-Domain" title="Top-Level-Domain">Top-Level-Domain</a> <a href=".org" title=".org">.org</a>. Der Verweis besteht aus mehreren <a href="NS_Resource_Record" title="NS Resource Record">NS Resource Records</a> sowie aus <a href="Glue_Record" class="mw-redirect" title="Glue Record">Glue Records</a> (A und AAAA Resource Records), die die IP-Adressen der Nameserver von <code>org.</code> enthalten.</li>

<li>Der rekursive Resolver fragt einen der Nameserver von <code>org.</code> nach <code>de.wikipedia.org.</code> Der Nameserver antwortet mit einem Verweis auf die Nameserver von <code>wikipedia.org.</code>, bestehend aus NS Resource Records und Glue Records.</li>

<li>Der rekursive Resolver fragt einen der Nameserver von <code>wikipedia.org.</code> nach <code>de.wikipedia.org.</code> Dieser ist autoritativ für die <a href="Zone_(DNS)" title="Zone (DNS)">Zone</a> <code>wikipedia.org.</code> und antwortet mit den angefragten A oder AAAA Resource Records.</li>

<li>Der rekursive Resolver schickt die Antwort an den Client zurück, welcher nun zum Beispiel eine <a href="Hypertext_Transfer_Protocol_Secure" title="Hypertext Transfer Protocol Secure">HTTPS</a>-Verbindung zu der IP-Adresse von <code>de.wikipedia.org.</code> aufbauen kann.</li></ol>

<div class="mw-heading mw-heading2"><h2 id="Erweiterungen">Erweiterungen</h2></div>

<p>Da sich das DNS als zuverlässig und flexibel erwiesen hat, wurden im Laufe der Jahre mehrere größere Erweiterungen eingeführt. Ein Ende dieses Trends ist nicht absehbar.

</p>

<div class="mw-heading mw-heading3"><h3 id="Dynamisches_DNS">Dynamisches DNS</h3></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Dynamisches_DNS" title="Dynamisches DNS">Dynamisches DNS</a></i></div>

<p>Die manuelle Änderung von DNS-Einträgen ist mit Aufwand verbunden. Durch <a href="DNS-Caching" title="DNS-Caching">DNS-Caching</a> kann es zudem mehrere Stunden oder sogar Tage dauern, bis sich eine Änderung im Netz verbreitet hat. Dynamisches DNS ermöglicht die automatisierte Aktualisierung von DNS-Einträgen. In Kombination mit der Verwendung eines niedrigen <a href="Time_to_Live" title="Time to Live">Time-to-Live-Werts</a> können Resource Records mit geringem Aufwand und geringer Zeitverzögerung aktualisiert werden. Ein typischer Einsatzzweck ist die automatische Aktualisierung von <a href="A_Resource_Record" title="A Resource Record">A</a> oder <a href="AAAA_Resource_Record" title="AAAA Resource Record">AAAA Resource Records</a> bei der Verwendung von <a href="Dynamische_IP-Adresse" class="mw-redirect" title="Dynamische IP-Adresse">dynamischen IP-Adressen</a>.

</p><p>Dynamisches DNS kann ein Sicherheitsrisiko darstellen, falls die Schnittstelle zur Aktualisierung von DNS-Einträgen nicht gegen unautorisierte Zugriffe abgesichert ist. Bei einer <a href="Representational_State_Transfer" title="Representational State Transfer">REST</a>-<a href="Programmierschnittstelle" title="Programmierschnittstelle">API</a> kann die Absicherung durch den Einsatz von <a href="HTTPS" class="mw-redirect" title="HTTPS">HTTPS</a> und einer <a href="Authentifizierung" title="Authentifizierung">Authentifizierung</a> des Clients erfolgen. Bei <a href="DNS-Update" class="mw-redirect" title="DNS-Update">DNS-Update</a> kann die Absicherung per <a href="TSIG" title="TSIG">TSIG</a> erfolgen.

</p>

<div class="mw-heading mw-heading3"><h3 id="Internationalisierung">Internationalisierung</h3></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Internationalisierter_Domainname" title="Internationalisierter Domainname">Internationalisierter Domainname</a></i></div>

<p>Bisher waren die Labels auf <a href="Alphanumerische_Zeichen" title="Alphanumerische Zeichen">alphanumerische Zeichen</a> und das Zeichen ‚-‘ eingeschränkt. Möglich, aber nicht standardkonform, ist bei Subdomains zudem ‚_‘. Dieser begrenzte Zeichenvorrat hängt vor allem damit zusammen, dass das DNS (wie auch das Internet ursprünglich) in den <a href="Vereinigte_Staaten" title="Vereinigte Staaten">USA</a> entwickelt wurde.

Damit waren in vielen Ländern gebräuchliche <a href="Schriftzeichen" title="Schriftzeichen">Schriftzeichen</a> (im deutschen Sprachraum zum Beispiel die <a href="Umlaut" title="Umlaut">Umlaute</a> ä, ö und ü sowie ß) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch) ursprünglich nicht in Domainnamen möglich.

</p><p>Ein mittlerweile etablierter Ansatz zur Vergrößerung des Zeichenvorrats ist die 2003 in RFC 3490<sup id="cite_ref-20" class="reference"><a href="#cite_note-20"><span class="cite-bracket">[</span>20<span class="cite-bracket">]</span></a></sup> eingeführte und 2010 mit RFC 5890<sup id="cite_ref-21" class="reference"><a href="#cite_note-21"><span class="cite-bracket">[</span>21<span class="cite-bracket">]</span></a></sup> aktualisierte Internationalisierung von Domainnamen (IDNA). Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit den bislang zulässigen Zeichen kodiert. Die erweiterten Zeichensätze werden dabei zunächst normalisiert, um unter anderem Großbuchstaben auf Kleinbuchstaben abzubilden, und anschließend per <a href="Punycode" title="Punycode">Punycode</a> auf einen ASCII-kompatiblen String abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (zum Beispiel <a href="Webbrowser" title="Webbrowser">Webbrowser</a>), die Nameserver-Infrastruktur (Server, Resolver) braucht jedoch nicht verändert zu werden. Im deutschsprachigen Raum können seit März 2004 deutsche, liechtensteinische, österreichische und schweizerische Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Auch bei anderen <a href="Top-Level-Domain" title="Top-Level-Domain">Top-Level-Domains</a>, insbesondere im asiatischen Raum, ist die Verwendung von internationalisierten Domainnamen möglich.

</p>

<div class="mw-heading mw-heading3"><h3 id="Extended_DNS">Extended DNS</h3></div>

<p>1999 beschrieb <a href="Paul_Vixie" title="Paul Vixie">Paul Vixie</a> im RFC 2671<sup id="cite_ref-22" class="reference"><a href="#cite_note-22"><span class="cite-bracket">[</span>22<span class="cite-bracket">]</span></a></sup> einige kleinere, abwärtskompatible Erweiterungen am Domain Name System, die als <a href="Extended_DNS" title="Extended DNS">Extended DNS</a> Version 0 bezeichnet werden. Durch Einsatz eines Pseudo-Records als Header-Erweiterung kann der Anfragende zusätzliche Optionen setzen. Insbesondere kann er übermitteln, dass er UDP-Antworten größer als 512 Bytes entgegennehmen kann. <a href="Domain_Name_System_Security_Extensions" title="Domain Name System Security Extensions">DNSSEC</a>-fähige Server und Resolver müssen EDNS beherrschen.

</p>

<div class="mw-heading mw-heading3"><h3 id="Verwaltung_von_Telefonnummern">Verwaltung von Telefonnummern</h3></div>

<p>Eine weitere aktuelle Erweiterung des DNS stellt <a href="Telephone_Number_Mapping" title="Telephone Number Mapping">ENUM</a> (RFC 2916<sup id="cite_ref-23" class="reference"><a href="#cite_note-23"><span class="cite-bracket">[</span>23<span class="cite-bracket">]</span></a></sup>) dar. Diese Anwendung ermöglicht die Adressierung von <a href="Internet" title="Internet">Internet</a>-Diensten über Telefonnummern, also das „Anwählen“ von per Internet erreichbaren Geräten mit dem aus dem Telefonnetz bekannten Nummerierungsschema.

Aus dem breiten Spektrum der Einsatzmöglichkeiten bietet sich insbesondere die Verwendung für <a href="Voice_over_IP" class="mw-redirect" title="Voice over IP">Voice-over-IP</a>-Diensten an.

</p>

<div class="mw-heading mw-heading3"><h3 id="RFID-Unterstützung"><span id="RFID-Unterst.C3.BCtzung"></span>RFID-Unterstützung</h3></div>

<p>Mit der <a href="RFID" title="RFID">RFID</a> können auf speziellen RFID-Etiketten abgelegte <a href="Identifikator" title="Identifikator">IDs</a> – sogenannte <a href="Elektronischer_Produktcode" title="Elektronischer Produktcode">elektronische Produktcodes</a> oder EPCs – berührungslos gelesen werden. Das DNS kann dazu verwendet werden, zu einer ID den Server zu ermitteln, der Daten über das zugehörige Objekt enthält. Der <a href="Object_Name_Service" title="Object Name Service">Object Name Service</a> (ONS) wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer (NAPTR).

</p>

<div class="mw-heading mw-heading3"><h3 id="Spam-Abwehr">Spam-Abwehr</h3></div>

<p>Zur Filterung von <a href="Spam" title="Spam">Spam</a>-Mails überprüfen viele <a href="Mailserver" title="Mailserver">Mailserver</a> den DNS-Eintrag des sendenden Mailservers routinemäßig mit Hilfe des <a href="Reverse_DNS" class="mw-redirect" title="Reverse DNS">Reverse-DNS</a>-Lookups. Dieser muss nicht nur auch vorwärts wieder korrekt auflösen und auf die IP-Adresse des sendenden Systems zeigen (<a href="Forward-confirmed_reverse_DNS" title="Forward-confirmed reverse DNS">Forward-confirmed reverse DNS</a>), sondern muss auch dem im SMTP-Protokoll genannten HELO-Hostnamen des sendenden Systems entsprechen.

</p><p>Mittels <a href="Sender_Policy_Framework" title="Sender Policy Framework">Sender Policy Framework</a> wird versucht, den Versand von gefälschten Absendern durch Dritte möglichst zu unterbinden. Zu jeder Mail-Domain wird dabei über einen speziellen <a href="SPF_Resource_Record" title="SPF Resource Record">SPF Resource Record</a> explizit aufgelistet, von welchen Servern und IP-Netzen mit E-Mails dieser Domain zu rechnen ist. SPF steht jedoch wegen zahlreicher technischer Schwierigkeiten, beispielsweise bei Weiterleitungen, in der Kritik.

</p><p>Auch der Anti-Spam-Mechanismus <a href="DomainKeys_Identified_Mail" title="DomainKeys Identified Mail">DKIM</a> greift auf Einträge im DNS zurück, indem sendende Mailserver in DNS-TXT-Records ihren Public-Key veröffentlichen, mit dem die Signatur ihrer ausgehenden E-Mails verifiziert werden kann.

</p>

<div class="mw-heading mw-heading3"><h3 id="Sonstiges">Sonstiges</h3></div>

<p>Neben den IP-Adressen können DNS-Namen auch <a href="Integrated_Services_Digital_Network" title="Integrated Services Digital Network">ISDN</a>-Nummern, <a href="X.25" title="X.25">X.25</a>-Adressen, <a href="Asynchronous_Transfer_Mode" title="Asynchronous Transfer Mode">ATM</a>-Adressen, <a href="%C3%96ffentlicher_Schl%C3%BCssel" class="mw-redirect" title="Öffentlicher Schlüssel">öffentliche Schlüssel</a>, Text-Zeilen usw. zugeordnet werden. In der Praxis sind derartige Anwendungsfälle aber die Ausnahme.

</p>

<div class="mw-heading mw-heading2"><h2 id="DNS_im_lokalen_Netz">DNS im lokalen Netz</h2></div>

<p>DNS ist nicht auf das Internet beschränkt. Es ist ohne weiteres möglich und mit der Definition verträglich, für die Auflösung lokaler Namen eigene Zonen im Nameserver einzurichten und dort die entsprechenden Adressen einzutragen. Der einmalige Aufwand zur Installation lohnt sich auch bei relativ kleinen Netzen, da dann alle Adressen im Netz zentral verwaltet werden können.

</p><p>Bei größeren Firmen oder Organisationen ist häufig ein aus lokalem und Internet-DNS bestehendes Mischsystem (<a href="Split-DNS" title="Split-DNS">Split-DNS</a>) anzutreffen. Die internen Nutzer greifen auf das lokale und die externen auf das Internet-DNS zu. In der Praxis können dadurch sehr komplizierte Konstellationen entstehen.

</p><p>Der DNS-Server <a href="BIND" title="BIND">BIND</a> kann auch mit <a href="Dynamic_Host_Configuration_Protocol" title="Dynamic Host Configuration Protocol">DHCP</a> zusammenarbeiten und damit für jeden Client im Netz eine Namensauflösung ermöglichen.

</p><p>Unter Windows gibt es noch einen anderen Dienst zur Namensauflösung – <a href="Windows_Internet_Naming_Service" title="Windows Internet Naming Service">WINS</a>, der eine ähnliche Funktion zur Verfügung stellt, allerdings ein anderes Protokoll verwendet.

</p>

<div class="mw-heading mw-heading2"><h2 id="DNS-Serververbund">DNS-Serververbund</h2></div>

<p>Es ist möglich, mehrere DNS-Server zu verbinden. Die primären Server sind für eine oder mehrere Domains verantwortlich. Die sekundären Server aktualisieren nach einer Änderung selbst die Daten, der Primäre verteilt diese Daten nicht automatisiert. Die Abholung der Daten wird über einen <a href="Zonentransfer" title="Zonentransfer">Zonentransfer</a> realisiert.

</p><p>Beispielsweise kann eine Firma mit mehreren Standorten an einem Platz einen primären Server für ihr internes DNS betreiben, der die Server in den Außenstellen versorgt. Der Zonentransfer geht bei BIND über TCP (per Default Port 53) und erfordert empfohlenerweise Authentifizierung. Die sekundären Server aktualisieren sich, wenn sich die Seriennummer für eine Zonendatei ändert oder sie eine entsprechende Nachricht vom primären Server erhalten. Die Freigabe für den Transferport sollte man per Firewall an die IP-Adresse des primären Servers binden. Bei anderen Softwarepaketen werden die Daten unter Umständen auf anderen Wegen abgeglichen, beispielsweise durch LDAP-Replikation, rsync, oder noch andere Mechanismen.

</p>

<div class="mw-heading mw-heading2"><h2 id="Sicherheit">Sicherheit</h2></div>

<p>Das DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur. Eine Störung kann erhebliche Kosten nach sich ziehen und eine Verfälschung von DNS-Daten Ausgangspunkt von Angriffen sein.

</p>

<div class="mw-heading mw-heading3"><h3 id="Angriffsformen">Angriffsformen</h3></div>

<p>Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw. zu erhalten. In seltenen Fällen wird versucht, den Internet-DNS durch <a href="Denial_of_Service" title="Denial of Service">Denial-of-Service</a>-Attacken komplett auszuschalten und so das Internet lahmzulegen. Außerdem kann das DNS dazu verwendet werden, gezielte Angriffe auf Einzelpersonen oder Unternehmen zu intensivieren.

</p>

<div class="mw-heading mw-heading4"><h4 id="DDoS-Angriff_auf_Nameserver">DDoS-Angriff auf Nameserver</h4></div>

<p>Bei einem <a href="Distributed_Denial_of_Service" class="mw-redirect" title="Distributed Denial of Service">Distributed-Denial-of-Service</a>-Angriff werden Nameserver durch einen hohen Datenstrom von DNS-Anfragen überlastet, so dass legitime Anfragen nicht mehr beantwortet werden können. Gegen DDoS-Angriffe auf Nameserver gibt es zurzeit keine Abwehrmöglichkeit. Als vorbeugende Maßnahme kann lediglich versucht werden, die Nameserver entsprechend zu dimensionieren bzw. ein verteiltes Netz mit möglichst vielen Servern zu installieren. Um eine große Anzahl DNS-Anfragen zu erzeugen, werden bei solchen Angriffen <a href="Botnet" title="Botnet">Botnetze</a> eingesetzt.

</p><p>Ein DDoS-Angriff kann unbeabsichtigt einen DNS-Server betreffen und zum Ausfall bringen, wenn der Domainname des Angriffsziels wiederholt aufgelöst wird ohne zwischengespeichert zu werden. Der Effekt auf DNS-Server wird verhindert, wenn das DDoS-Schadprogramm <a href="DNS-Caching" title="DNS-Caching">DNS-Caching</a> verwendet.

</p>

<div class="mw-heading mw-heading4"><h4 id="DNS-Amplification-Angriff">DNS-Amplification-Angriff</h4></div>

<p>Die <a href="DNS_Amplification_Attack" title="DNS Amplification Attack">DNS Amplification Attack</a> ist ein <a href="Denial_of_Service" title="Denial of Service">Denial-of-Service</a>-Angriff, bei der nicht der DNS-Server selbst das eigentliche Angriffsziel ist, sondern ein Dritter. Ausgenutzt wird, dass ein DNS-Server in manchen Fällen auf kurze Anfragen sehr lange Antworten zurücksendet. Durch eine gefälschte Absenderadresse werden diese an die IP-Adresse des Opfers gesendet. Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substanziell verstärken und so den Internet-Zugang seines Angriffsziels stören.

</p>

<div class="mw-heading mw-heading3"><h3 id="DNS-Spoofing">DNS-Spoofing</h3></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="DNS-Spoofing" title="DNS-Spoofing">DNS-Spoofing</a></i></div>

<p>Beim DNS-Spoofing handelt es sich um eine Angriffsklasse von Maskierungsangriffen, die das Ziel haben eine falsche Identität vorzugeben. Dafür wird die DNS-Antwort an einen Client verändert um ihn auf einen anderen, meist vom Angreifer kontrollierten Dienst fehlzuleiten.

</p>

<div class="mw-heading mw-heading4"><h4 id="DNS-Cache-Poisoning">DNS-Cache-Poisoning</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="DNS-Cache-Poisoning" class="mw-redirect" title="DNS-Cache-Poisoning">DNS-Cache-Poisoning</a></i></div>

<p>DNS-Cache-Poisoning bezeichnet ein Angriffsszenario, welches in die Angriffsklasse des DNS-Spoofing fällt. Dabei werden einem anfragenden Client zusätzlich zu der korrekten Antwort, manipulierte Daten übermittelt, die dieser in seinen Cache übernimmt und später, möglicherweise ungeprüft, verwendet.

</p>

<div class="mw-heading mw-heading4"><h4 id="Offener_DNS-Server">Offener DNS-Server</h4></div>

<p>Wer einen autoritativen DNS-Server für seine eigenen Domains betreibt, muss natürlich für Anfragen von beliebigen IP-Adressen offen sein. Um zu verhindern, dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden (z. B. für Angriffe auf Root-Server), erlaubt BIND es, die Antworten auf die eigenen Domains einzuschränken. Beispielsweise bewirkt die Option <code>allow-recursion {127.0.0.1; 172.16.1.4;};</code>, dass rekursive Anfragen, d. h. Anfragen auf andere Domains, ausschließlich für den lokalen Host (localhost) sowie 172.16.1.4 beantwortet werden. Alle anderen IP-Adressen bekommen nur auf Anfragen auf eigene Domains eine Antwort.

</p><p>Ein offener DNS-Server kann auch eine Falle sein, wenn er gefälschte IP-Adressen zurückgibt, siehe <a href="Pharming_(Internet)" title="Pharming (Internet)">Pharming</a>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Sicherheitserweiterungen">Sicherheitserweiterungen</h3></div>

<p>Mehr als zehn Jahre nach der ursprünglichen Spezifikation wurde DNS um Security-Funktionen ergänzt. Folgende Verfahren sind verfügbar:

</p>

<div class="mw-heading mw-heading4"><h4 id="DNSSEC">DNSSEC</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Domain_Name_System_Security_Extensions" title="Domain Name System Security Extensions">Domain Name System Security Extensions</a></i></div>

<p>Bei DNSSEC (Domain Name System Security Extensions) wird von einem <a href="Asymmetrisches_Kryptosystem" title="Asymmetrisches Kryptosystem">asymmetrischen Kryptosystem</a> Gebrauch gemacht. Neben der Server-Server-Kommunikation kann auch die Client-Server-Kommunikation gesichert werden. Dies soll die Manipulation der Antworten erschweren.

</p>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="DNS_over_TLS" title="DNS over TLS">DNS over TLS</a></i></div>

<p>Bei <i>DNS over TLS</i> sollen sowohl DDoS-Angriffe, die Manipulation der Antworten als auch das Ausspähen der gesendeten Daten verhindert werden. Dazu werden die DNS-Abfragen per <a href="Transport_Layer_Security" title="Transport Layer Security">Transport Layer Security</a> (TLS) abgesichert.<sup id="cite_ref-StrotmannSchmidt_24-0" class="reference"><a href="#cite_note-StrotmannSchmidt-24"><span class="cite-bracket">[</span>24<span class="cite-bracket">]</span></a></sup>

</p>

<p>DNS over <a href="Quick_UDP_Internet_Connections" class="mw-redirect" title="Quick UDP Internet Connections">QUIC</a> soll die Vorteile von DoT und DoH kombinieren. DoQ soll gute Privatsphäre und Sicherheit bieten, eine geringe Latenz aufweisen und nicht blockierbar sein.<sup id="cite_ref-25" class="reference"><a href="#cite_note-25"><span class="cite-bracket">[</span>25<span class="cite-bracket">]</span></a></sup> RFC 9250<sup id="cite_ref-26" class="reference"><a href="#cite_note-26"><span class="cite-bracket">[</span>26<span class="cite-bracket">]</span></a></sup> der <a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">Internet Engineering Task Force</a> beschreibt DoQ.<sup id="cite_ref-27" class="reference"><a href="#cite_note-27"><span class="cite-bracket">[</span>27<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="DNS_over_HTTPS_(DoH)"><span id="DNS_over_HTTPS_.28DoH.29"></span>DNS over HTTPS (DoH)</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="DNS_over_HTTPS" title="DNS over HTTPS">DNS over HTTPS</a></i></div>

<p>DNS over HTTPS ändert das DNS-System grundlegend. Anfragen finden hier auf Anwendungsebene statt. Anwendungen wie beispielsweise der Webbrowser fragen direkt beim DNS-Server an, anstatt die Anfrage an das Betriebssystem weiterzuleiten. Dadurch sehen DNS-Anfragen aus wie normaler Internetverkehr und können somit nicht gezielt abgefangen bzw. blockiert werden.<sup id="cite_ref-StrotmannSchmidt_24-1" class="reference"><a href="#cite_note-StrotmannSchmidt-24"><span class="cite-bracket">[</span>24<span class="cite-bracket">]</span></a></sup>

</p><p><a href="Cloudflare" title="Cloudflare">Cloudflare</a> und <a href="Google_LLC" title="Google LLC">Google</a> bieten öffentliche DoH-Webserver an. <a href="Mozilla_Firefox" title="Mozilla Firefox">Mozilla Firefox</a> unterstützt DoH ab Version 60 als experimentelle Funktion. Mozilla stellt in Zusammenarbeit mit Cloudflare einen DoH-Server bereit, der strenge Privatsphäre-Anforderungen erfüllen muss.<sup id="cite_ref-StrotmannSchmidt_24-2" class="reference"><a href="#cite_note-StrotmannSchmidt-24"><span class="cite-bracket">[</span>24<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-28" class="reference"><a href="#cite_note-28"><span class="cite-bracket">[</span>28<span class="cite-bracket">]</span></a></sup>

</p>

<p>DNS kann über <a href="Virtual_Private_Network" title="Virtual Private Network">virtuelle private Netzwerke</a> (VPNs) und <a href="Tunnel_(Rechnernetz)#Tunnelprotokoll" title="Tunnel (Rechnernetz)">Tunneling-Protokolle</a> betrieben werden. Eine Anwendung, die seit 2019 so weit verbreitet ist, dass sie ein eigenes, häufig verwendetes Akronym rechtfertigt, ist DNS over <a href="Tor_(Netzwerk)" title="Tor (Netzwerk)">Tor</a>.

</p>

<p>Bei TSIG (Transaction Signatures) handelt es sich um ein einfaches, auf <a href="Symmetrisches_Kryptosystem" title="Symmetrisches Kryptosystem">symmetrischen Schlüsseln</a> beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern und Updates von <a href="Client" title="Client">Clients</a> gesichert werden kann.

</p>

<div class="mw-heading mw-heading2"><h2 id="Domain-Registrierung">Domain-Registrierung</h2></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Domain-Registrierung" title="Domain-Registrierung">Domain-Registrierung</a></i></div>

<p>Um DNS-Namen im Internet bekannt machen zu können, muss der Besitzer die Domain, die diesen Namen enthält, registrieren. Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind. Domain-Registrierungen werden von Organisationen (Registries, z. B. Verisign oder Afilias) vorgenommen, die dazu von der <a href="Internet_Assigned_Numbers_Authority" title="Internet Assigned Numbers Authority">IANA</a> bzw. <a href="Internet_Corporation_for_Assigned_Names_and_Numbers" title="Internet Corporation for Assigned Names and Numbers">ICANN</a> autorisiert wurden. Registrierungen sind (von wenigen Ausnahmen abgesehen) gebührenpflichtig. Für Domains unter .de ist die <a href="DENIC" title="DENIC">DENIC</a> zuständig. In den allermeisten Fällen können Domains bei den Registries nur über Zwischenhändler, sogenannte Registrare wie Godaddy oder 1&1 Internet SE registriert werden, die mit den Registries entsprechende Verträge abgeschlossen haben.

</p>

<div class="mw-heading mw-heading2"><h2 id="Bonjour_bzw._Zeroconf">Bonjour bzw. Zeroconf</h2></div>

<p><a href="Apple" title="Apple">Apple</a> hat bei der Entwicklung von <a href="MacOS" title="MacOS">macOS</a> mehrere Erweiterungen am DNS vorgenommen, welche die umfassende Selbstkonfiguration von Diensten in LANs ermöglichen soll. Zum einen wurde <a href="Multicast_DNS" class="mw-redirect" title="Multicast DNS">Multicast DNS</a> („mDNS“) eingeführt, das die Namensauflösungen in einem <a href="Local_Area_Network" title="Local Area Network">LAN</a> ohne einen dedizierten Namensserver erlaubt. Zusätzlich wurde noch DNS-SD (für „DNS Service Discovery“) eingeführt, die die Suche („Browsing“) nach Netzwerkdiensten in das DNS beziehungsweise mDNS ermöglicht. mDNS und DNS-SD sind bisher keine offiziellen <a href="Request_for_Comments" title="Request for Comments">RFCs</a> des <a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">IETF</a>, sind aber trotzdem bereits in verschiedenen (auch freien) Implementierungen verfügbar. Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen „<a href="Zeroconf" title="Zeroconf">Zeroconf</a>“ zusammen, als Bestandteil von OS X auch als „Rendezvous“ bzw. „<a href="Bonjour_(Apple)" title="Bonjour (Apple)">Bonjour</a>“. Die meisten Linux-Distributionen unterstützen diese Erweiterung z. B. mit der <a href="Avahi_(Software)" title="Avahi (Software)">avahi</a>-Implementierung von Zeroconf.

</p>

<div class="mw-heading mw-heading2"><h2 id="Zensur_und_alternative_DNS">Zensur und alternative DNS</h2></div>

<p>Standardmäßig wird der DNS-Servern durch den <a href="Mobilfunkanbieter" title="Mobilfunkanbieter">Mobilfunkanbieter</a> ausgewählt, oder durch die Anwendung die gerade genutzt wird. <a href="Mozilla_Firefox" title="Mozilla Firefox">Mozilla Firefox</a> verwendet bspw. <a href="Cloudflare" title="Cloudflare">Cloudflare</a> um DNS-Anfragen aufzulösen. Innerhalb eines Netzwerkes, oder lokal auf einem Gerät, kann jedoch nach eigener Präferenz ein DNS-Server eingestellt werden.

</p>

<div class="mw-heading mw-heading3"><h3 id="Unzensierte_DNS-Server">Unzensierte DNS-Server</h3></div>

<p>Seit der Debatte um das <a href="Zugangserschwerungsgesetz" title="Zugangserschwerungsgesetz">Zugangserschwerungsgesetz</a> (2008) und <a href="Zensur_im_Internet" title="Zensur im Internet">Zensur im Internet</a> im Allgemeinen gibt es eine Reihe von alternativen DNS-Anbietern, die Domains nach eigener Aussage nicht zensieren.

Beispiele sind Organisationen wie <a href="Digitalcourage" title="Digitalcourage">Digitalcourage</a>, <a href="Freifunk" title="Freifunk">Freifunk</a> München<sup id="cite_ref-29" class="reference"><a href="#cite_note-29"><span class="cite-bracket">[</span>29<span class="cite-bracket">]</span></a></sup> oder <a href="Digitale_Gesellschaft_(Schweiz)" title="Digitale Gesellschaft (Schweiz)">Digitale Gesellschaft</a>. Auch von Privatpersonen werden alternative DNS-Server bereitgestellt.<sup id="cite_ref-privacy-handbuch_30-0" class="reference"><a href="#cite_note-privacy-handbuch-30"><span class="cite-bracket">[</span>30<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-31" class="reference"><a href="#cite_note-31"><span class="cite-bracket">[</span>31<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Dienste_mit_Filterlisten">Dienste mit Filterlisten</h3></div>

<p>Es kann unterschiedliche Gründe geben einen DNS-Server zu nutzen, der mit <a href="Schwarze_Liste" title="Schwarze Liste">Schwarzen Listen</a> arbeitet, also bestimmte Anfragen an Webseiten nicht auflöst. So können gezielt Werbetreibende blockiert werden (siehe auch: <a href="Werbeblocker" title="Werbeblocker">Werbeblocker</a>), auch gibt es Anbieter, die versprechen, die Cybersicherheit oder die Privatsphäre zu verbessern. Das Blockieren von nicht jugendfreien Inhalten ist ein weiterer Einsatzzweck. Technisch betrachtet handelt es sich bei der Verwendung von Filterlisten um eine Zensur von Inhalten. Die Grenzen zur Meinungszensur sind jedoch unscharf und werden subjektiv empfunden. Einige Anbieter führen Blocklisten über <a href="Fake_News" title="Fake News">Fake-News</a>-Websiten; die Kriterien, nach denen die Einordnung erfolgt, sind hierbei teilweise nicht offengelegt. Große Anbieter, die blockierende DNS-Server betreiben, sind unter anderen: <a href="Quad9" title="Quad9">Quad9</a>, Mullvad und Adguard. Die EU kündigte 2022 an, einen eigenen DNS-Server etablieren zu wollen (DNS4EU), dieser soll ebenfalls mit Filterlisten arbeiten und Netzsperren umsetzen.<sup id="cite_ref-32" class="reference"><a href="#cite_note-32"><span class="cite-bracket">[</span>32<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Namecoin">Namecoin</h3></div>

<p>Namecoin ist der erste <a href="Abspaltung_(Softwareentwicklung)" title="Abspaltung (Softwareentwicklung)">Fork</a> von <a href="Bitcoin" title="Bitcoin">Bitcoin</a> aus dem Jahr 2011 und findet Anwendung als <a href="Kryptow%C3%A4hrung" title="Kryptowährung">Kryptowährung</a> sowie als <a href="Schl%C3%BCssel-Werte-Datenbank" title="Schlüssel-Werte-Datenbank">Key-Value Store</a> für Domainnamen und Identitäten. Als alternatives verteiltes Domain Name System (DNS) außerhalb des <a href="Internet_Corporation_for_Assigned_Names_and_Numbers" title="Internet Corporation for Assigned Names and Numbers">ICANN</a>-Namensraumes werden Transaktionen zum Registrieren, Aktualisieren und Übertragen von Domains auf der <a href="Blockchain" title="Blockchain">Blockchain</a> aufgezeichnet. Zur Auflösung der .bit-Adressen werden ein Browserplugin oder ein lokaler Namecoin DNS-Server benötigt. Ebenso wie Bitcoin ist Namecoin ein dezentrales <a href="Peer-to-Peer" title="Peer-to-Peer">Peer-to-Peer</a>-System, das keiner Zensur unterliegt.<sup id="cite_ref-33" class="reference"><a href="#cite_note-33"><span class="cite-bracket">[</span>33<span class="cite-bracket">]</span></a></sup> Die Software ist <a href="Open_Source" title="Open Source">Open Source</a> und wird auf <a href="GitHub" title="GitHub">GitHub</a> gehostet.<sup id="cite_ref-34" class="reference"><a href="#cite_note-34"><span class="cite-bracket">[</span>34<span class="cite-bracket">]</span></a></sup>

</p><p>Einem Bericht von <i>Trend Micro</i> zufolge wurden .bit-Domains seit 2013 vermehrt auch von <a href="Internetkriminalit%C3%A4t" title="Internetkriminalität">Cyberkriminellen</a> genutzt.<sup id="cite_ref-35" class="reference"><a href="#cite_note-35"><span class="cite-bracket">[</span>35<span class="cite-bracket">]</span></a></sup> Vornehmlich aus diesem Grund hat das <a href="OpenNIC" title="OpenNIC">OpenNIC</a>-Projekt im Sommer 2019 seine DNS-Auflösung von .bit-Domains eingestellt.<sup id="cite_ref-36" class="reference"><a href="#cite_note-36"><span class="cite-bracket">[</span>36<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Nameserversoftware">Nameserversoftware</h2></div>

<p>Auswahl bekannter Software für Namensauflösung.

</p>

<ul><li><a href="BIND" title="BIND">BIND</a> (Berkeley Internet Name Domain) ist die meistgebrauchte Nameserversoftware und gilt als Referenzimplementierung der meisten <a href="Request_for_Comments" title="Request for Comments">RFCs</a> zu DNS. Die erste Version von BIND war die erste öffentlich verfügbare Nameserver-Implementierung.</li>

<li>CoreDNS ist ein in <a href="Go_(Programmiersprache)" title="Go (Programmiersprache)">Go</a> geschriebener DNS-Server der <a href="Cloud_Native_Computing_Foundation" title="Cloud Native Computing Foundation">Cloud Native Computing Foundation</a>.</li>

<li>Bei <a href="Djbdns" title="Djbdns">djbdns</a> hat der Autor <a href="Daniel_J._Bernstein" title="Daniel J. Bernstein">Daniel J. Bernstein</a> eine Prämie für das Finden von Sicherheitsproblemen ausgeschrieben. Djbdns wird von Bernstein nicht mehr weiterentwickelt, weil er es als fertig ansieht.</li>

<li>Dnsmasq ist ein Nameserver und DHCP-Server mit eingeschränkter Funktionalität. Es werden die Namen aus dem lokalen Netz entsprechend /etc/hosts aufgelöst. Dnsmasq verfügt über keinen vollständigen Resolver: unbekannte Namensanfragen werden weitergeleitet und im Cache gespeichert.</li>

<li>Knot DNS ist ein autoritativer Nameserver, der von <a href="CZ.NIC" title="CZ.NIC">CZ.NIC</a> entwickelt wird, dem Betreiber von <a href=".cz" title=".cz">.cz</a>.</li>

<li>Microsoft Windows DNS ist eine der wenigen kommerziellen Nameserver-Implementierungen als Teil der Produktreihe <a href="Microsoft_Windows_Server" class="mw-redirect" title="Microsoft Windows Server">Microsoft Windows Server</a>. Der Nameserver unterstützt dynamische Updates, Zonentransfers und Notification. Zonendaten können in den aktuellen Versionen im <a href="Active_Directory_Service" class="mw-redirect" title="Active Directory Service">Active Directory</a> oder in Zonendateien gespeichert und repliziert werden.</li>

<li><a href="Name_Server_Daemon" title="Name Server Daemon">Name Server Daemon</a> ist ein autoritativer Nameserver, der zum Einsatz als Top-Level-Domain- und <a href="Root-Nameserver" title="Root-Nameserver">Root-Nameserver</a> entwickelt wurde. NSD kompiliert Antworten statisch vor, um die Server-Performance zu optimieren. Dynamische Zoneninhalte oder <a href="Lastverteilung_per_DNS" title="Lastverteilung per DNS">Round Robin</a> werden nicht unterstützt.</li>

<li><a href="PowerDNS" title="PowerDNS">PowerDNS</a> ist ein Nameserver, der Zonen aus <a href="SQL" title="SQL">SQL</a>-Datenbanken, <a href="Lightweight_Directory_Access_Protocol" title="Lightweight Directory Access Protocol">LDAP</a>-Verzeichnissen und anderen Backends lesen kann. PowerDNS begann als kommerzielle Implementierung und ist seit 2002 unter der <a href="GNU_General_Public_License" title="GNU General Public License">GPL</a> lizenziert.</li>

<li><a href="Unbound" title="Unbound">Unbound</a> ist ein DNS-Resolver, der DNSSEC-Validierung und Caching unterstützt. Unbound kann als Softwarebibliothek in Anwendungen eingebunden werden.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1034" class="extiw external" title="rfc:1034">1034</a></span></i> – <i><span lang="en">Domain Names – Concepts and Facilities</span></i>. 1987 (englisch).</li>

<li><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1035" class="extiw external" title="rfc:1035">1035</a></span></i> – <i><span lang="en">Domain Names – Implementation and Specification</span></i>. 1987 (englisch).</li>

<li><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2181" class="extiw external" title="rfc:2181">2181</a></span></i> – <i><span lang="en">Clarifications to the DNS Specification</span></i>. (englisch).</li>

<li><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2782" class="extiw external" title="rfc:2782">2782</a></span></i> – <i><span lang="en">A DNS RR for specifying the location of services (DNS SRV)</span></i>. (englisch).</li></ul></li>

<li><a rel="nofollow" class="external text" href="http://multicastdns.org/">Multicast DNS</a></li>

<li>Funktionsweise und Verwaltung des DNS als <a rel="nofollow" class="external text" href="http://www.dubberly.com/maps/domain-name-system.html">Poster</a></li>

<li>Beiträge des <a href="Chaos_Computer_Club" title="Chaos Computer Club">Chaos Computer Clubs</a>

<ul><li>Zensur durch DNS-Server: <a rel="nofollow" class="external text" href="http://www.ccc.de/censorship/dns-howto/">DNS Howto</a></li>

<li>Podcast zum Thema DNS: <a rel="nofollow" class="external text" href="http://cre.fm/cre099">Chaosradio Express 099 – Domain Name System</a></li></ul></li>

<li>Julia Evans: <a rel="nofollow" class="external text" href="https://wizardzines.com/comics/life-of-a-dns-query/"><i>Life of a DNS query</i>.</a> Wizard Zines (DNS-Abfrage als <a href="Comic" title="Comic">Comic</a>)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7858" class="extiw external" title="rfc:7858">7858</a></span></i> – <i><span lang="en">Specification for DNS over Transport Layer Security (TLS)</span></i>. Mai 2016 (englisch).</span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc8094" class="extiw external" title="rfc:8094">8094</a></span></i> – <i><span lang="en">DNS over Datagram Transport Layer Security (DTLS)</span></i>. Februar 2017 (englisch).</span>

</li>

<i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1034" class="extiw external" title="rfc:1034">1034</a></span></i> – <i><span lang="en">Domain Names – Concepts and Facilities</span></i>. 1987 (englisch).</span>

</li>

<i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1035" class="extiw external" title="rfc:1035">1035</a></span></i> – <i><span lang="en">Domain Names – Implementation and Specification</span></i>. 1987 (englisch).</span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text">Artikel 4 Nr. 14 der <span class="-print"><a rel="nofollow" class="external text" href="https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016L1148">Richtlinie (EU) 2016/1148</a></span></span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text"><a href="Paul_Mockapetris" title="Paul Mockapetris">Paul Mockapetris</a>: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc882" class="extiw external" title="rfc:882">882</a></span></i> – <i><span lang="en">Domain Names – Concepts and Facilities</span></i>. November 1983 (englisch).</span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text"><a href="Paul_Mockapetris" title="Paul Mockapetris">Paul Mockapetris</a>: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc883" class="extiw external" title="rfc:883">883</a></span></i> – <i><span lang="en">Domain Names – Implementation and Specification</span></i>. November 1983 (englisch).</span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2181#section-11" class="extiw external" title="rfc:2181">2181</a></span></i> – <i><span lang="en">Clarifications to the DNS Specification</span></i>. Abschnitt 11: <i>Name syntax</i>. (englisch).</span>

</li>

</li>

<li id="cite_note-rfc8499-10"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-rfc8499_10-0">a</a></sup> <sup><a href="#cite_ref-rfc8499_10-1">b</a></sup> <sup><a href="#cite_ref-rfc8499_10-2">c</a></sup></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc8499" class="extiw external" title="rfc:8499">8499</a></span></i> – <i><span lang="en">DNS Terminology</span></i>. Januar 2019 (englisch).</span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><a href="#cite_ref-11">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7766#section-1" class="extiw external" title="rfc:7766">7766</a></span></i> – <i><span lang="en">DNS Transport over TCP – Implementation Requirements</span></i>. März 2010, Abschnitt 1: <i>Introduction</i>. (englisch). “<span lang="en">This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. […] It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts.</span>”</span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><a href="#cite_ref-12">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.4" class="extiw external" title="rfc:1035">1035</a></span></i> – <i><span lang="en">Domain Names – Implementation and Specification</span></i>. 1987, Abschnitt 2.3.4: <i>Size limits</i>. (englisch).</span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc6891#section-6.2.5" class="extiw external" title="rfc:6891">6891</a></span></i> – <i><span lang="en">Extension Mechanisms for DNS (EDNS(0))</span></i>. April 2013, Abschnitt 6.2.5: <i>Payload Size Selection</i>. (englisch).</span>

</li>

<li id="cite_note-flagday2020-14"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-flagday2020_14-0">a</a></sup> <sup><a href="#cite_ref-flagday2020_14-1">b</a></sup></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.dnsflagday.net/2020/">dnsflagday.net</a></span>

</li>

</li>

<li id="cite_note-16"><span class="mw-cite-backlink"><a href="#cite_ref-16">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc6891#section-4.3" class="extiw external" title="rfc:6891">6891</a></span></i> – <i><span lang="en">Extension Mechanisms for DNS (EDNS(0))</span></i>. April 2013, Abschnitt 4.3: <i>UDP Message Size</i>. (englisch).</span>

</li>

<li id="cite_note-rfc5936-17"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-rfc5936_17-0">a</a></sup> <sup><a href="#cite_ref-rfc5936_17-1">b</a></sup></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc5936#section-2" class="extiw external" title="rfc:5936">5936</a></span></i> – <i><span lang="en">DNS Zone Transfer Protocol (AXFR)</span></i>. Juni 2010, Abschnitt 2: <i>AXFR Messages</i>. (Ende; gem#ß <a href="https://datatracker.ietf.org/doc/html/rfc1035" class="extiw external" title="rfc:1035">RFC:1035</a>, englisch).</span>

</li>

<li id="cite_note-18"><span class="mw-cite-backlink"><a href="#cite_ref-18">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7766#section-6.2" class="extiw external" title="rfc:7766">7766</a></span></i> – <i><span lang="en">DNS Transport over TCP – Implementation Requirements</span></i>. März 2010, Abschnitt 6.2: <i>Recommendations</i>. (englisch).</span>

</li>

<li id="cite_note-19"><span class="mw-cite-backlink"><a href="#cite_ref-19">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc6724#section-2.1" class="extiw external" title="rfc:6724">6724</a></span></i> – <i><span lang="en">Default Address Selection for Internet Protocol Version 6 (IPv6)</span></i>. September 2012, Abschnitt 2.1: <i>Policy Table</i>. (englisch). “<span lang="en">Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available.</span>”</span>

</li>

<li id="cite_note-20"><span class="mw-cite-backlink"><a href="#cite_ref-20">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc3490" class="extiw external" title="rfc:3490">3490</a></span></i> – <i><span lang="en">Internationalizing Domain Names in Applications (IDNA)</span></i>. März 2003 (englisch).</span>

</li>

<li id="cite_note-21"><span class="mw-cite-backlink"><a href="#cite_ref-21">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc5890" class="extiw external" title="rfc:5890">5890</a></span></i> – <i><span lang="en">Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</span></i>. August 2010 (englisch).</span>

</li>

<li id="cite_note-22"><span class="mw-cite-backlink"><a href="#cite_ref-22">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2671" class="extiw external" title="rfc:2671">2671</a></span></i> – <i><span lang="en">Extension Mechanisms for DNS (EDNS0)</span></i>. August 1999 (englisch).</span>

</li>

<li id="cite_note-23"><span class="mw-cite-backlink"><a href="#cite_ref-23">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2916" class="extiw external" title="rfc:2916">2916</a></span></i> – <i><span lang="en">E.164 number and DNS</span></i>. September 2000 (englisch).</span>

</li>

<li id="cite_note-StrotmannSchmidt-24"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-StrotmannSchmidt_24-0">a</a></sup> <sup><a href="#cite_ref-StrotmannSchmidt_24-1">b</a></sup> <sup><a href="#cite_ref-StrotmannSchmidt_24-2">c</a></sup></span> <span class="reference-text"><span class="cite">Carsten Strotmann, Jürgen Schmidt: <i>DNS mit Privacy und Security vor dem Durchbruch.</i> Ehemals im <span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=https%3A%2F%2Fwww.heise.de%2Fct%2Fausgabe%2F2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html">Original</a></span> (nicht mehr online verfügbar)<span>;</span><span class="Abrufdatum"> abgerufen am 25. Juli 2018</span>.<span style="display:none"><a rel="nofollow" class="external text" href="http://deadurl.invalid/https://www.heise.de/ct/ausgabe/2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html">@1</a></span><span style="display:none"><a rel="nofollow" class="external text" href="https://www.heise.de/ct/ausgabe/2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html">@2</a></span><span style="display:none">Vorlage:Toter Link/www.heise.de</span> <small>(Seite nicht mehr abrufbar. <a rel="nofollow" class="external text" href="http://timetravel.mementoweb.org/list/2010/https://www.heise.de/ct/ausgabe/2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html">Suche in Webarchiven</a>)</small></span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=DNS+mit+Privacy+und+Security+vor+dem+Durchbruch&rft.description=DNS+mit+Privacy+und+Security+vor+dem+Durchbruch&rft.identifier=https%3A%2F%2Fwww.heise.de%2Fct%2Fausgabe%2F2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html&rft.creator=Carsten+Strotmann%2C+J%C3%BCrgen+Schmidt"> </span></span>

</li>

<li id="cite_note-25"><span class="mw-cite-backlink"><a href="#cite_ref-25">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.privacy-handbuch.de/handbuch_93.htm"><i>DoQ soll nicht manipulierbar sein, die gleiche Privatsphäre wie DoT bieten, eine geringe Latenz wie unverschlüsseltes DNS über UDP und nicht blockierbar sein wie DoH.</i></a><span class="Abrufdatum"> Abgerufen am 28. Januar 2021</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=DoQ+soll+nicht+manipulierbar+sein%2C+die+gleiche+Privatsph%C3%A4re+wie+DoT+bieten%2C+eine+geringe+Latenz+wie+unverschl%C3%BCsseltes+DNS+%C3%BCber+UDP+und+nicht+blockierbar+sein+wie+DoH&rft.description=DoQ+soll+nicht+manipulierbar+sein%2C+die+gleiche+Privatsph%C3%A4re+wie+DoT+bieten%2C+eine+geringe+Latenz+wie+unverschl%C3%BCsseltes+DNS+%C3%BCber+UDP+und+nicht+blockierbar+sein+wie+DoH&rft.identifier=https%3A%2F%2Fwww.privacy-handbuch.de%2Fhandbuch_93.htm"> </span></span>

</li>

<li id="cite_note-26"><span class="mw-cite-backlink"><a href="#cite_ref-26">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc9250" class="extiw external" title="rfc:9250">9250</a></span></i> – <i><span lang="en">DNS over Dedicated QUIC Connections</span></i>. Mai 2022 (englisch).</span>

</li>

<li id="cite_note-27"><span class="mw-cite-backlink"><a href="#cite_ref-27">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.heise.de/news/Verbesserte-Namensaufloesung-IETF-veroeffentlicht-RFC-zum-Internetprotokoll-QUIC-7097921.html"><i>Verbesserte Namensauflösung: IETF veröffentlicht RFC zum Internetprotokoll QUIC.</i></a> In: <i>heise online.</i><span class="Abrufdatum"> Abgerufen am 20. Juli 2022</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=Verbesserte+Namensaufl%C3%B6sung%3A+IETF+ver%C3%B6ffentlicht+RFC+zum+Internetprotokoll+QUIC&rft.description=Verbesserte+Namensaufl%C3%B6sung%3A+IETF+ver%C3%B6ffentlicht+RFC+zum+Internetprotokoll+QUIC&rft.identifier=https%3A%2F%2Fwww.heise.de%2Fnews%2FVerbesserte-Namensaufloesung-IETF-veroeffentlicht-RFC-zum-Internetprotokoll-QUIC-7097921.html"> </span></span>

</li>

<li id="cite_note-28"><span class="mw-cite-backlink"><a href="#cite_ref-28">↑</a></span> <span class="reference-text"><span class="cite">Patrick McManus: <a rel="nofollow" class="external text" href="https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/"><i>Improving DNS Privacy in Firefox.</i></a><span class="Abrufdatum"> Abgerufen am 26. Juli 2018</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=Improving+DNS+Privacy+in+Firefox&rft.description=Improving+DNS+Privacy+in+Firefox&rft.identifier=https%3A%2F%2Fblog.nightly.mozilla.org%2F2018%2F06%2F01%2Fimproving-dns-privacy-in-firefox%2F&rft.creator=Patrick+McManus&rft.language=en"> </span></span>

</li>

<li id="cite_note-29"><span class="mw-cite-backlink"><a href="#cite_ref-29">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://ffmuc.net/wiki/doku.php?id=knb:dohdot">DNS-over-HTTPS und DNS-over-TLS Unterstützung.</a> ffmuc.net</span>

</li>

<li id="cite_note-privacy-handbuch-30"><span class="mw-cite-backlink"><a href="#cite_ref-privacy-handbuch_30-0">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.privacy-handbuch.de/handbuch_93d.htm"><i>Vertrauenswürdige DNS-Server.</i></a><span class="Abrufdatum"> Abgerufen am 19. Februar 2021</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=Vertrauensw%C3%BCrdige+DNS-Server&rft.description=Vertrauensw%C3%BCrdige+DNS-Server&rft.identifier=https%3A%2F%2Fwww.privacy-handbuch.de%2Fhandbuch_93d.htm"> </span></span>

</li>

<li id="cite_note-31"><span class="mw-cite-backlink"><a href="#cite_ref-31">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.privacytools.io/providers/dns/"><i>Encrypted DNS Resolvers.</i></a><span class="Abrufdatum"> Abgerufen am 3. Mai 2021</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=Encrypted+DNS+Resolvers&rft.description=Encrypted+DNS+Resolvers&rft.identifier=https%3A%2F%2Fwww.privacytools.io%2Fproviders%2Fdns%2F&rft.language=en"> </span></span>

</li>

<li id="cite_note-32"><span class="mw-cite-backlink"><a href="#cite_ref-32">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://netzpolitik.org/2022/dns4eu-eu-will-eigenen-dns-server-mit-filterlisten-und-netzsperren/"><i>EU will eigenen DNS-Server mit Filterlisten und Netzsperren.</i></a><span class="Abrufdatum"> Abgerufen am 16. Oktober 2023</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=EU+will+eigenen+DNS-Server+mit+Filterlisten+und+Netzsperren&rft.description=EU+will+eigenen+DNS-Server+mit+Filterlisten+und+Netzsperren&rft.identifier=https%3A%2F%2Fnetzpolitik.org%2F2022%2Fdns4eu-eu-will-eigenen-dns-server-mit-filterlisten-und-netzsperren%2F"> </span></span>

</li>

<li id="cite_note-33"><span class="mw-cite-backlink"><a href="#cite_ref-33">↑</a></span> <span class="reference-text"><span class="cite">Kevin Helms: <a rel="nofollow" class="external text" href="https://news.bitcoin.com/obtain-use-bit-privacy-domains/"><i>How to Obtain and Use .Bit Privacy Domains.</i></a> In: <i>Bitcoin News.</i> 7. März 2017,<span class="Abrufdatum"> abgerufen am 19. März 2020</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=How+to+Obtain+and+Use+.Bit+Privacy+Domains&rft.description=How+to+Obtain+and+Use+.Bit+Privacy+Domains&rft.identifier=https%3A%2F%2Fnews.bitcoin.com%2Fobtain-use-bit-privacy-domains%2F&rft.creator=Kevin+Helms&rft.date=2017-03-07&rft.language=en"> </span></span>

</li>

<li id="cite_note-34"><span class="mw-cite-backlink"><a href="#cite_ref-34">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.namecoin.org/"><i>Namecoin.</i></a><span class="Abrufdatum"> Abgerufen am 6. März 2020</span> (englisch, Projektwebsite).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=Namecoin&rft.description=Namecoin&rft.identifier=https%3A%2F%2Fwww.namecoin.org%2F&rft.language=en"> </span></span>

</li>

<li id="cite_note-35"><span class="mw-cite-backlink"><a href="#cite_ref-35">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://abuse.ch/blog/dot-bit-the-next-generation-of-bulletproof-hosting/"><i>.bit – The next Generation of Bulletproof Hosting.</i></a> In: <i>abuse.ch.</i> 25. September 2017,<span class="Abrufdatum"> abgerufen am 19. März 2020</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=.bit+%E2%80%93+The+next+Generation+of+Bulletproof+Hosting&rft.description=.bit+%E2%80%93+The+next+Generation+of+Bulletproof+Hosting&rft.identifier=https%3A%2F%2Fabuse.ch%2Fblog%2Fdot-bit-the-next-generation-of-bulletproof-hosting%2F&rft.date=2017-09-25&rft.language=en"> </span></span>

</li>

<li id="cite_note-36"><span class="mw-cite-backlink"><a href="#cite_ref-36">↑</a></span> <span class="reference-text"><span class="cite">Catalin Cimpanu: <a rel="nofollow" class="external text" href="https://www.zdnet.com/article/opennic-drops-support-for-bit-domain-names-after-rampant-malware-abuse/"><i>OpenNIC drops support for .bit domain names after rampant malware abuse.</i></a> In: <i>ZDNet.</i> 17. Juli 2019,<span class="Abrufdatum"> abgerufen am 19. März 2020</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADomain+Name+System&rft.title=OpenNIC+drops+support+for+.bit+domain+names+after+rampant+malware+abuse&rft.description=OpenNIC+drops+support+for+.bit+domain+names+after+rampant+malware+abuse&rft.identifier=https%3A%2F%2Fwww.zdnet.com%2Farticle%2Fopennic-drops-support-for-bit-domain-names-after-rampant-malware-abuse%2F&rft.creator=Catalin+Cimpanu&rft.date=2019-07-17&rft.language=en"> </span></span>

</li>

</ol>

<div>

Normdaten (Sachbegriff): <a href="Gemeinsame_Normdatei" title="Gemeinsame Normdatei">GND</a>: <span class="-print"><a rel="nofollow" class="external text" href="https://d-nb.info/gnd/4348318-5">4348318-5</a></span> </div>

</div></div></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-11-19" href="https://de.wikipedia.org/wiki/?title=Domain_Name_System&oldid=261677634">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>